-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Use normalized tuples for fallback calculation #19111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use normalized tuples for fallback calculation #19111
Conversation
This comment has been minimized.
This comment has been minimized.
@ilevkivskyi sorry to bother you again, I'd appreciate a review - this PR fixes a crash and you should be well familiar with the affected part. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, unfortunately this whole normalization story is a bit tricky (partially because of design limitations of semanal_typeags.py
). FWIW I think for now some "reactive" bug fixing is OK, but at some point we may need to think about tightening this a bit more.
# https://github.com/python/mypy/issues/19105 | ||
from typing import Unpack | ||
|
||
class A(tuple[Unpack[tuple[int]]]): ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please also add a test for
class C(tuple[Unpack[tuple[int, ...]]]): ...
(unless there is already such test case)? I am not sure we properly handle such types. Also maybe test not just class creation, but some tuple ops as well, such as e.g. unpacking etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surprisingly we don't have such a test too, but it was already working before my patch - *tuple[int, ...]
is not a trivial unpack. But your feeling is overall correct - I'm able to make it crash with
a: A
tuple(a)
and also get a terrible diagnostic on
b: B
_, = b # E: Variadic tuple unpacking requires a star target
despite B clearly not being variadic. I'll move this to draft for now, there's little benefit from merging a crash fix that causes a next one immediately...
Does this perhaps also cover (part of) #17282? |
…9105-trivial-unpack-in-base-class-tuple
@jorenham probably not |
This comment has been minimized.
This comment has been minimized.
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LG, but I have one question.
@@ -102,6 +102,8 @@ def visit_type_alias_type(self, t: TypeAliasType) -> None: | |||
# If there was already an error for the alias itself, there is no point in checking | |||
# the expansion, most likely it will result in the same kind of error. | |||
get_proper_type(t).accept(self) | |||
if t.alias is not None: | |||
t.alias.accept(self) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a duplicate work, did you try deleting the accept just above? (if you delete it, don't forget to update the comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That breaks one test:
[case testValidTypeAliasValues]
from typing import TypeVar, Generic, List
T = TypeVar("T", int, str)
S = TypeVar("S", int, bytes)
class C(Generic[T]): ...
class D(C[S]): ... # E: Invalid type argument value for "C"
U = TypeVar("U")
A = List[C[U]]
x: A[bytes] # E: Value of type variable "T" of "C" cannot be "bytes"
V = TypeVar("V", bound=int)
class E(Generic[V]): ...
B = List[E[U]]
y: B[str] # E: Type argument "str" of "E" must be a subtype of "int"
Removing this line makes both errors on alias instantiation disappear. That's quite expected since get_proper_type
calls _expand_once
, so it is not equivalent to simply accepting the target alias - we do not want to ignore args here. We can limit that to only accepting if args are non-empty, but I don't think this can result in any significant speedup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, this is kind of unfortunate. We already accept args in isolation at the very start (see super call), then we accept expansion, and finally the target in isolation. But I guess this is the price to pay for having both:
- Support for unrestricted type vars in alias definitions
- Doing some in-place patching in this visitor
Fixes #19105. I haven't checked this with namedtuples magic, nor am I certain that this is the best way.